The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In a group of network devices, each device may have one or more network identities that serve as a locator or unique identifier of the device. Network identities may be static, which means that the identities are not expected to change, or dynamic, which means that the identities may change unexpectedly. Examples of network identity include Internet Protocol version 4 (IPv4) addresses and IPv6 addresses.
A Dynamic Group VPN (DGVPN) allows authorized devices, each having an assigned network identity, to securely communicate with each other even in situations where setting up a mesh of pair-wise security associations is challenging. A DGVPN may be configured, for example, using Cisco GETVPN technology commercially available from Cisco Systems, Inc., San Jose, Calif.
In a DGVPN, a Group Member (GM) may register to a key server computer (KS) and may obtain group security associations to encrypt and decrypt communications exchanged with other members. A group association need not be specific to a network identity of the GM. From the perspective of the DGVPN, once the GM registration process is finished, the network identity of the GM is immaterial.
However, from the perspective of a KS, a network identity of a GM may matter. For example, a KS may use a network identity of a GM to disseminate rekey messages to the GM. Consequently, conventional key servers, including those that implement a DGVPN, usually rely on static network identities for the GMs.
Relying on static network identities of GMs may impede the expansion of a DGVPN to provide support for static or mobile nodes, whose network identities may dynamically change. By their nature, mobile nodes may dynamically acquire different network identities as they move from one network to another. In that case, a conventional KS relying on a static network identity may be unable to deliver rekeying information to such nodes acting as the GMs. Subsequently, the mobile GM may become isolated from the group, upon its existing key expiration. It is worth pointing out that while multicast based rekey distribution could avoid KS having to rely on the network identities of GMs, distributing multicast rekey messages is not always possible because a coherent multicast routing may not be implementable within the network.